home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group99a.txt
/
000173_icon-group-sender _Mon Aug 2 16:52:39 1999.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
4KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA20277
for icon-group-addresses; Mon, 2 Aug 1999 16:50:42 -0700 (MST)
Message-Id: <199908022350.QAA20277@baskerville.CS.Arizona.EDU>
Date: Tue, 3 Aug 1999 10:50:09 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@hermes.otago.ac.nz>
To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU
Subject: Re: When Do You Keep A Quirk?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
It sounds as though the right thing to do is to withdraw the
basename function *entirely*.
I'd like to point out that the situation in UNIX is actually
rather confused, thanks to some people adding 'neat hacks'.
Solaris:
basename string [suffix]
deletes any prefix ending in / (does that mean '/' or does it
mean _any_ directory separator? matters on DOS/Windows/OS/2)
suffix, if present, is a REGULAR EXPRESSION; if there is a
tail of string matching suffix, it will be removed (but if
there are _several_ such tails, _which_?)
XPG4, BSD
basename string [suffix]
same rule and problem with string; but suffix is a LITERAL
and NONE of its characters are significant. There is for
example nothing special about '.'.
C library:
basename(path)
does NOT take a suffix argument; removes leading directory
prefixes by smashing its argument. It also deletes any
trailing slashes, except that a path that is one or more
slashes and nothing else yields "/". A null pointer or an
empty string yields ".".
In particular,
basename latex .tex
could give you 'l' or 'latex' depending on which of
/usr/bin /usr/xpg4/bin comes first in your $PATH.
The basename command combines two operations:
remove_directory_part
which is what the basename() function does, and
remove_matching_extension
which has no corresponding library function. Nor is the function
I've _really_ wanted often enough,
remove_any_extension
provided in any form.
I firmly believe that the _best_ thing to do is to junk basename and
its relatives completely and to provide a 'pathname' library modelled
on Common Lisp. The second best thing to do is to throw 'basename'
out as being just too confusing, and to provide two _new_
library functions
remove_directory_part(FileName) ->
FileName without any (drive or) directory part.
name (if present), extension (if present), and
version number (if present) are retained.
remove_extension(FileName[, Extension]) ->
if Extension is provided,
ignore any leading dot to get Extension',
remove trailing . Extension' from FileName if present,
no change to FileName if . Extension' not present
if Extension not provided,
remove trailing . ext from FileName if present,
where ext is anything host file system allows in an
extension.
Leave any directory part intact.
return modified FileName.
When writing new code, you can use these without wondering which
version of `basename', if any, Icon `basename' corresponds to.
Old code will promptly break. If it assumed the documented
behavior of basename, just plug in
basename(F, E) = remove_extension(remove_directory_part(F), E)
basename(F) = remove_directory_part(F)
If it assumed the actual behaviour, just plug in
basename(F) = remove_extension(remove_directory_part(F))
One of the best things about Java is @deprecated, obviously swiped
from Eiffel's 'obsolete' keyword. In Eiffel, you can write
<procedure heading>
obsolete "<string>"
<procedure body>
and the compiler writes the string as a warning if your program uses
that procedure. Icon could do with something similar for cases like this.